Java 的語言概念就是囉唆，加上時代的演進，概念也越多，囉唆加上囉唆就是更囉唆，不過也可以講好聽一點就是「精準用字」，精準是有其優點的，但是就是名詞越來越多，要理解後，正確的用字，合理的使用，就是「專業」的一個表現。不然混淆濫用會造成更多的誤會（我後來都戲稱這是程式加密，防人偷，專門誤導別人，讓人看不懂的加密）。

不同框架/概念對於同一種東西，有其理念上的定義名稱，不過在實作上可能看起來都一樣（一支class，各自表述，搞不好還有人可以解釋超出原作者的想法XD），對於定義商業物件，之前用Bean（getter/setter），現在大多使用 POJO 概念（plain old Java object，wiki：https://en.wikipedia.org/wiki/Plain_old_Java_object ）。

而POJO底下還可以分成好幾種應用型態的物件（雖然都是看設計者要怎麼定），若配Spring Data JPA 套路的，這篇文章寫得蠻不錯的 https://hackmd.io/@MonsterLee/HJyAdgRBB 。我也常這樣用這樣的概念，然後把其定義做為class naming 的字尾，這樣在看程式時，只要看字尾，就可以知道這個是用於什麼地方的東西。

目前常用到的字尾為：

• PO (persistent object)
  • 用於對應資料庫欄位的物件，注入 @Entity
  • 會搭配 @Convert mapping 資料庫與Java 物件的對應
  • 可以使用Java Enum，控制項目好防呆
  • 可以於DB儲存 json 字串，Java上直接是物件可操作使用，方便不用再轉。我通常用於描述資料，額外擴充動態資料，或是整份資料的儲存（ex: 被審核的內容原稿，當時問卷調查的原始資料。）
• DTO (Data Transfer Object)
  • 封裝為API/網頁ajax 使用的物件，或是放在Controller Model attribute內的物件，為與 外部系統（API）/前端/UI View溝通的物件結構。差不多就是以前早期的VO（view object，MVC 裡面的view，跟value object 又不一樣，只是縮寫看起來一樣。我對他的定義是可以給別人/使用者看的資料）主要用途
  • 可以說是看得到（外部API/前端顯示）的資料物件
• BO (business object)
  • 主要依據SA定義項目的物件設定，商業邏輯物件，在處理複雜或很長的商業資料流時使用。
  • 通常都會有配特定的service 來使用（非單純DB存取資料處理）
  • 可以單用，或是給別人繼承使用
• Prop(property)
  • 這個在我自己的定義內，他一定是 interface。通常是為了Controller/Service 通用實作歸納出來的屬性，例如資料的建立時間，建立者資訊…等等。
  • Prop 跟 BO 的差別就是，Prop是 interface，為SD視角（為了系統開發共通共用實作做出來的底層共用）。BO是 class，為SA視角（商業流程）。

若是由 SA 開DB schema時，通常DB內容就包含很多的商業邏輯（SA就是熟DB/SQL運作，自然會將資料做成DB好處理的），所以 PO 常常會跟 BO 有蠻大的重疊部份，於軟體開發流程，是有故事情節上的先後關係沒錯。

現在碰到比較多都是系統整合的架構，不少資料都是透過外部API方式取得（早期還蠻多系統整合，喜歡用DB view做溝通，但現在時代不太一樣了），所以在實作上，把PO跟BO視為兩種獨立個體比較好，但若是資料copy時可能會麻煩，這時候可以利用 json 物件特性轉換 copy value 的方式，相同內容的屬性，就取好同一名稱，就可以順利的多階層轉換出來，也可以避免操作PO，不小心改到資料的問題！（每次都會看到有人撈PO，沒有clone成另外的物件就附加額外資訊時，就會看到DB資料亂掉的Bug…）

透過定義物件字尾，可以快速的分別這個物件是用在什麼地方。不過因為分層可能會有一直繼承上去的關係，要不要真的就寫一行定義 ex: AbcDTO extends AbcPO 就當一個POJO，就是看開發政策了。實質內容沒有差異，要不要多寫一層，就各有優缺點就是。

在定義程式物件時（這個就算SD範圍了），比較容易煩惱的大概就是，要照SA出的內容整個照抄一個對一個，還是幫他歸納再抽幾層純程式應用邏輯出來當abstract實作。好的 abstract 可以少寫很多的code，有點類似80/20的概念，不過當然程式沒那麼好康可以到那麼高的比率，不過只要有共用，有個通用寫法是比較省工，底層好好測一次沒問題，後面的就不用一直重測一樣的東西。

這個就是一條龍的缺點，會不自覺的想到各個階段的困擾（因為再怎樣都是打到自己的工作）。如果高度分工的話，就是丟給別人想就好，反正下游卡住做不下去就會有回饋意見了，不想住海邊，歸責做好就可以，頂多email回覆超～長一串，或是會開不完…嗯…不要變成吵架就好。

只是不分工的話，一條龍也是看人，有時後便宜行事，也有可能埋了地雷沒人知道，這世界就是這麼的沒有兩全其美的方式QQ。做事容易，做人難阿…